CASE STUDY // FINTECH INFRASTRUCTURE
agentic-engineering / k8s-addon-upgrades
Platform Engineering & SRE

How a global platform team cut Kubernetes add-on upgrade cycles from weeks to days with agentic engineering

Twelve production EKS clusters. Forty-plus add-ons per upgrade. A team of eight replaced manual runbooks with governed AI agents — and turned a six-week slog into a 30-minute assessment.

Industry
FinTech Infrastructure
Infrastructure
Amazon EKS (Multi-Cluster)
Scale
12 prod clusters · 500+ engineers
Team
Platform + SRE · 8 FTEs
Agentic upgrade pipeline overview
FIG. 01 — the agentic upgrade pipeline, end to end
Executive Summary

From six weeks of archaeology to a single governed session

For a global platform team, managing the Kubernetes lifecycle was becoming an uphill battle. With dozens of add-ons per cluster and rapidly growing infrastructure, a single upgrade could consume up to six weeks of manual effort — days buried in release notes, fragile Helm forks, and validation checks that offered little certainty of success.

Seeking a way out, the team moved beyond simple AI assistance to a governed agentic engineering approach: fragmented, ad-hoc workflows replaced with a unified, intelligent lifecycle. By integrating live cluster inventory, versioned agent skills, and automated in-cluster validation, they built a system that doesn't just suggest changes — it orchestrates them with precision and governance.

The results were profound. What once took weeks of tedious research and manual execution is now a structured, multi-hour session — compressing upgrade cycles from weeks to days while restoring confidence with an auditable, repeatable playbook for enterprise-grade Kubernetes operations.

Key takeaways
  • 01Upgrade cycles dropped from 3–6 weeks of manual work to ~30 minutes of automated assessment plus a multi-hour agent session.
  • 02The stack runs 26 allowlisted MCP tools, 4 versioned agent skills, and detection for 8 distinct IaC patterns.
  • 03Every upgrade passes human-in-the-loop capability gates — cluster mutation and RBAC changes require explicit approval, off by default.
  • 04Upgrades are validated in-cluster — resource health, API readiness, end-to-end checks — never assumed from pod status alone.
  • 05Spans 12 production EKS clusters and 500+ engineers at a FinTech infrastructure company.
6→0.5weeks compressed to hours
40+add-ons assessed per EKS bump
26allowlisted MCP tools
8IaC patterns detected
Situation & Complication

Success became an unsustainable operational burden

As the organization's infrastructure scaled, every minor EKS update triggered a complex chain of dependencies across more than 40 add-ons — with no centralized source of truth to manage it.

  • 0140+ add-ons to assess for EOL status, compatibility, and breaking changes on every EKS minor bump
  • 02Release notes scattered across GitHub, vendor docs, and internal wikis
  • 03IaC spread across multiple patterns — forked Helm charts, Terraform helm_release, Argo CD Applications, raw manifests
  • 04No single source of truth for what was actually installed vs. what Git declared
  • 05Generic AI tools that could edit files but had no cluster context, no version control on instructions, and no validation framework

Attempts to use generic AI tools only highlighted the gap. While these assistants could edit code, they lacked the cluster context and validation frameworks needed for safe production changes — a complexity gap that led to delayed security adoptions and team burnout.

Business impact: delayed Kubernetes version adoption, security exposure on EOL add-ons, engineer burnout, and leadership hesitation to approve production upgrades.
The Agentic Engineering Solution

Agents engineered into the upgrade lifecycle, not bolted onto it

Rather than adding a chatbot to existing runbooks, the team built agents into every stage of the lifecycle — from observation to validation — across a multi-service platform.

01

Observe — live cluster inventory

A CronJob deployed into every cluster's platform namespace runs every 12 hours, collecting 60+ Kubernetes resource kinds plus all CRDs and custom resources, capturing cluster metadata (K8s version, cloud provider, node groups, environment labels), and uploading compressed manifest batches to a central ingestion API.

Upgrade assessments reflect what is actually running, not stale spreadsheets
02

Know — always-on knowledge agents

A knowledge pipeline keeps upgrade intelligence current without manual curation:

AgentRoleTechnology
Compatibility MapperAutomates EOL & compatibility mappingWorkflow engine + Proposer/Judge LLM loop
Release Notes CuratorTransforms raw changelogs into labeled release notesExtract → Categorize → Severity → Human review
Upgrade AdvisorRecommends whether/when to upgrade each add-onMCP evaluators + deterministic verdict
Breaking-Change AnalystEnriches application-client breaking changes for human reviewLLM service + git clone
Compatibility research that took days per add-on is available at assessment time
03

Assess — upgrade lifecycle orchestration

When a platform engineer triggers an Upgrade Assessment for a target K8s version:

  • A workflow engine starts a generation job (~30 min)
  • The assessment engine reads cluster scan data, upgrade recommendations, and curated release notes
  • It produces package install changes — one per add-on needing upgrade — with reasons and breaking-change previews
  • Stages and steps surface in the upgrade console, including IDE deep-links that open the next agent session with context pre-loaded
One assessment covers all add-ons instead of N separate research threads
04

Package — context bundles + MCP tooling

26 MCP tools and a context bundle format let AI agents work locally instead of stuffing the LLM window. The planning agent skill creates assessments, selects projects, generates context, and writes a handoff manifest for the next agent.

context-bundle
# addon-v1.14.4-v1.17.2-snapshot.tar.gz ├── base/ ← upstream current chart ├── remote/ ← upstream target chart ├── upgrade-plan.json ← reasons + notable changes └── *-crds.yaml ← target-version CRDs
Agents receive portable, checksum-validated upgrade intelligence — not ad-hoc copy-paste
05

Execute — versioned agent skills

Semver agent skills — not one-off prompts — ship with MCP allowlists and capability gates:

SkillPurpose
Planning skillAssessment → project selection → context generation
IaC upgrade skill8-pattern IaC detection + three-way merge
Validation skillIn-cluster validation Jobs
Assessment-driven upgrade skillAssessment-guided upgrade path

The IaC upgrade skill detects 8 IaC patterns (forked charts, Terraform Helm, Argo CD, raw manifests, and more), builds a Values Delta Map, runs a three-way merge via the platform CLI, and enforces a 100% action-completeness gate before claiming success.

IaC edits are deterministic and pattern-aware, not generic "update the chart version" suggestions
06

Validate — safety, health & readiness checks

Automated preflight/postflight validation is a first-class upgrade step: resource health (deployment/pod status), API readiness (webhook and API connectivity), and end-to-end checks that create test resources and verify real functionality — for example, confirming cert-manager can issue a certificate. The validation agent skill resolves the correct container image per project and version, surfaces RBAC for human approval, and runs checks as in-cluster Jobs.

Upgrades are proven in-cluster, not assumed from green pods
How It Works

The agentic upgrade lifecycle, visualized

Agentic upgrade lifecycle diagram
FIG. 02 — the full lifecycle: observe, know, assess, package, execute, validate
Standardized upgrade workflow diagram
FIG. 03 — the standardized upgrade workflow, from trigger to sign-off
Results: Before → After

Cycle time, compressed

Before — manual3–6 weeks
After — agentic~30 min assessment + session
MetricBefore (manual)After (agentic)Impact
Cycle time3–6 weeks~30 min + sessionParallel efficiency
ResearchManual archaeologyLiving maps + AI advisorsActive knowledge graph
ExecutionUngoverned promptsSemver skills + MCPAuditable governance
Validationkubectl get podsEnd-to-end checksProven readiness
Platform Metrics

What the platform runs on

26
MCP tools exposed
context + MCP service
4
Versioned lifecycle skills
agent skill registry
8
IaC patterns detected
IaC upgrade skill
Maturity Model

Manual vs. agentic upgrade maturity

Qualitative index from platform architecture design, scored 1–5.

Cluster inventory
— agentic
Compatibility research
— agentic
Upgrade assessment
— agentic
● grey = manual · ● blue = agentic — 1 (low) to 5 (high)
Outcomes Checklist

What "governed agentic" actually means in production

Governed AI execution — agents cannot call arbitrary APIs; only allowlisted MCP tools per skill version
Deterministic IaC changes — eight-pattern detection + three-way merge + 100% completeness gate
Living knowledge graph — compatibility and release-note agents keep maps current without manual spreadsheets
Context-aware upgrades — cluster inventory + assessment + context bundles mean agents know what to change
In-cluster validation — readiness checks prove upgrades work, not just pod status
Human-in-the-loop by design — capability gates, assessment selection, RBAC approval, step tracking
Audit trail — semver skills, object-store context snapshots, workspace transaction logs, validation run reports
Composable architecture — skills, MCP, and knowledge agents evolve independently with validation
Technology Stack

What's under the hood

LayerComponentKey technologies
GovernanceAgent skill registryGo, object storage, serverless
ExecutionLifecycle agent skillsMarkdown recipes, Cursor
Golden Nuggets

Campaign proof points

01

Agent skill registry = package manager for AI behavior. Git → validate → publish → MCP bootstrap at runtime.

02

Proposer–Judge loops. Compatibility and upgrade-advisor agents separate AI proposals from AI verification before anything ships.

03

Context bundles beat context windows. Charts stay on disk; agents read plan metadata and merge locally.

04

100% completeness invariant. The IaC upgrade skill forbids partial success claims.

05

Six capability gates default off. Cluster mutation and RBAC changes require explicit human approval.

06

IDE deep-links. Upgrade steps open Cursor with assessment context pre-wired.

07

From observe to validate in one platform. No tool switching across the upgrade lifecycle.

Related Capabilities
Frequently Asked Questions
How long does a Kubernetes add-on upgrade normally take?
Manually, assessing and upgrading add-ons like cert-manager, Istio, Argo CD, and external-dns across a multi-cluster EKS environment typically takes 3–6 weeks per upgrade cycle, due to scattered release notes and no single source of truth for what's installed.
What is agentic engineering in a Kubernetes context?
Agentic engineering means giving AI agents live cluster context, versioned skills, and allowlisted MCP tools so they can plan, execute, and validate infrastructure changes — rather than just generating text suggestions a human has to manually apply.
What is an MCP tool?
MCP (Model Context Protocol) tools are allowlisted functions an AI agent can call to interact with real systems — in this case, 26 MCP tools gave agents governed access to cluster inventory, release notes, and IaC repositories.
Does agentic AI replace human approval in production upgrades?
No. The system uses human-in-the-loop gates — capability gates for cluster mutation and RBAC changes default to off and require explicit human approval before an agent can act.
What IaC patterns does the upgrade skill support?
Eight patterns, including forked Helm charts, Terraform helm_release, Argo CD Applications, and raw manifests, using a three-way merge with a 100% action-completeness gate.